Systems and methods for emergency response dispatch

ABSTRACT

Computerized method for coordinating decentralized response to emergency events includes receiving at least one request for emergency assistance, alerting registered responders in a geographic area corresponding to an emergency site of said request for emergency assistance, acknowledging a response from at least one of the responders agreeing to dispatch to the emergency site. The computerized method can also include one or more of confirming arrival of said at least one responder at the emergency site, determining a need for additional resources, confirming transportation to a destination facility, confirming arrival of said at least one responder the at the destination facility, receiving a summary report of actions undertaken, and/or recognition of said at least one responder by the system to be available to receive subsequent requests for emergency assistance.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/976,868, filed Apr. 8, 2014, which is incorporated by referenceherein in its entirety.

BACKGROUND

The disclosed subject matter is generally related to devices, systemsand methods for emergency response dispatch, including systems andmethods for implementing and facilitating emergency response dispatchutilizing mobile telecommunications infrastructure.

Emergency response systems can reduce or prevent premature death anddisability due to emergency events by improving access to firstresponders and reducing delays in emergency transport for people in needof assistance. Emergency response systems can be delivered, for example,through conventional ambulance and emergency medical services (EMS)systems. However, such emergency response systems can be limited orunavailable in certain areas, for example in rural areas, as well as indeveloping countries, at least in part because of limited emergencyresources or because the telecommunications infrastructure utilized fordispatching first responders may not be sufficiently established.Without such infrastructure, directing emergency resources to timelyreach people requesting assistance when emergency events occur can bedifficult.

Emergency response dispatching systems can connect people in need withappropriate first responders to facilitate timely dispatch of emergencyresponse to emergency events. For example, in most areas of the U.S.,people in need of emergency assistance can use the well-known 9-1-1access code to alert first responders. However, capital investments andrecurring costs needed to build and sustain such emergencytelecommunications technologies in certain areas, for example in ruralareas, as well as in developing countries can be cost prohibitive, whichmay delay or limit such initiatives. Additional factors, includingpoorly-maintained or non-existent public infrastructure, limitedavailability of GPS devices, inadequate maps, low literacy levels, amongother factors, can provide additional challenges to implementingemergency response systems.

As such, death and disability from emergency conditions—including, forexample and without limitation, conditions arising from road trafficinjuries, complicated childbirth, among other emergencies—continue tochallenge efforts in certain areas to timely dispatch emergencyresponders where and when needed. There remains a need for emergencydispatch response systems to overcome these challenges that can beaffordably deployed, for example with little or no additionalinfrastructure.

SUMMARY

The purpose and advantages of the disclosed subject matter will be setforth in and apparent from the description that follows, as well as willbe learned by practice of the disclosed subject matter. Additionaladvantages of the disclosed subject matter will be realized and attainedby the methods and systems particularly pointed out in the writtendescription and claims hereof, as well as from the appended drawings.

To achieve these and other advantages and in accordance with the purposeof the disclosed subject matter, as embodied and broadly described, thedisclosed subject matter includes techniques for coordinatingdecentralized response to emergency events. An exemplary techniqueincludes receiving at least one request for emergency assistance,alerting registered responders in a geographic area corresponding to anemergency site of said request for emergency assistance, acknowledging aresponse from at least one of the responders agreeing to dispatch to theemergency site, and confirming arrival of said at least one responder atthe emergency site.

Additionally, and as embodied herein, exemplary techniques can includereceiving a request for additional resources from the at least oneresponder, notifying at least one additional responder in the geographicarea of the request for additional resources, obtaining a response fromthe at least one additional responder agreeing to dispatch to theemergency site, attaining confirmation of the arrival of the at leastone additional responder at the emergency site, confirming atransportation status and a destination facility from the emergencysite, confirming arrival of the emergency transportation at thedestination facility, and confirming availability of the at least oneresponder. Additionally or alternatively, and as embodied herein,exemplary techniques can include determining a threshold number ofresources to respond to the at least one request, and allocating anumber of the responders not to exceed the threshold number ofresources.

Furthermore, and as embodied herein, exemplary techniques can includeproviding a summary report of response times to the at least oneresponder. Confirming arrival of said at least one responder can includereceiving updated location information of the emergency site from areporting party or said at least one responder at the emergency site.Exemplary techniques can include storing location information of theemergency site, and producing reports and statistics based on thelocation information.

In addition, and as embodied herein, exemplary techniques can includerecording and storing communications between reporting parties,responders, and receiving facilities for tracking. Exemplary techniquescan include determining a response time of the at least one responderand storing the at least one response time. Exemplary techniques caninclude determining a suitable level of support for the request foremergency assistance. Exemplary techniques can include cancelingpreviously sent requests to responders when the suitable level ofsupport has been confirmed.

The disclosed subject matter also includes a system for coordinatingdecentralized response to emergency events having some or all of thefeatures described herein. As recognized in the art, exemplary systemdisclosed herein can include some or all of the features describedherein, or any suitable combination thereof.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and are intended toprovide further explanation of the disclosed subject matter claimed.

The accompanying drawings, which are incorporated in and constitute partof this specification, are included to illustrate and provide a furtherunderstanding of the method and system of the disclosed subject matter.Together with the description, the drawings serve to explain theprinciples of the disclosed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram illustrating exemplary techniques forcoordinating decentralized response to emergency events.

FIG. 2 is a flow diagram illustrating exemplary techniques forcoordinating decentralized response to emergency events.

FIGS. 3A-3H together are a flow diagram illustrating exemplarytechniques for coordinating decentralized response to emergency events.

FIG. 4 is a diagram illustrating an exemplary mobile client device foruse with the disclosed subject matter.

FIG. 5 is a diagram illustrating an exemplary system for implementingemergency response dispatch according to the disclosed subject matter.

DETAILED DESCRIPTION

Reference will now be made in detail to the various exemplaryembodiments of the disclosed subject matter, exemplary embodiments ofwhich are illustrated in the accompanying drawings. The structure andcorresponding method of operation of the disclosed subject matter willbe described in conjunction with the detailed description of the system.

In accordance the disclosed subject matter herein, a computerized methodfor coordinating decentralized response to emergency events is provided.The computerized method generally includes coordinating decentralizedresponse to emergency events, receiving at least one request foremergency assistance, alerting registered responders, includinglayperson and/or trained responders, in a geographic catchment areacorresponding to an emergency site of said request for emergencyassistance, acknowledging a response from at least one of the respondersagreeing to dispatch to the emergency site, and confirming arrival ofsaid at least one responder at the emergency site.

The accompanying figures, where like reference numerals refer toidentical or functionally similar elements throughout the separateviews, serve to further illustrate various embodiments and to explainvarious principles and advantages all in accordance with the disclosedsubject matter. For purpose of explanation and illustration, and notlimitation, exemplary embodiments of systems and methods for emergencyresponse dispatch in accordance with the disclosed subject matter areshown in FIGS. 1-5. While the present disclosed subject matter isdescribed with respect to using the systems and methods for dispatch ofemergency medical services, one skilled in the art will recognize thatthe disclosed subject matter is not limited to the illustrativeembodiment. The systems and methods for emergency response dispatch canbe applied, for example, to police and fire response, flood or othernatural disaster response, crowd control, and any other applicationssuitable to utilize resource dispatching on demand. Furthermore,automated, decentralized emergency dispatch systems as described hereincan be utilized to augment existing emergency response services, forexample when existing services have limited range or are overwhelmed bydemand.

FIGS. 1-3 are diagrams illustrating exemplary embodiments of thedisclosed subject matter. With reference to FIG. 1, at 10, a request foremergency assistance can be received, for example via text message,voice call, or smartphone application. With reference to FIG. 3A, asembodied herein at 302, the request can be received directly by thesystem from the requestor, for example by processing a text messagerequest for assistance and/or receiving location data from smartphoneapplication or a GPS-enabled device. Alternatively, the request can bereceived by an operator, for example by voice or text message, who caninput the request into the system.

A Reporting Party (RP) contacts system-dispatch, alerting the need forassistance; system-dispatch collects location and other identifiersthrough verbal or digital communication; when received, system-dispatchrelays a Request for Assistance and appropriate information to FirstResponders marked as “Logged-In” or recognized by the system as“Available” in a given geographic region, providing pertinentinformation to First Responders and requesting the First Responders toConfirm Response, including estimated time of arrival in minutes.Alternatively, the First Responders can Deny Response, thus indicatingthat the First Responder is unable or unwilling to provide assistance.The system can wait for the reply from First Responders, and can confirmto the Reporting Party that the system is Contacting Assistance, whichcan be performed, for example and without limitation, by voice message,text message, or any other suitable messaging technique.

A plurality of Requesting Parties can request emergency assistance fromone or more locations simultaneously. The system can accept all suchrequests, track each request, and organize and store data pertaining toeach request. For example, each request can be assigned a unique name orother suitable identifier. Furthermore, each communication pertaining toa particular request can be grouped together, for example in a threadedgrouping of messages. The data can be stored, for example for subsequentreview, analysis, and/or reporting. As embodied herein, the system cangenerate reports on various statistical data and/or metrics, for exampleand without limitation, providing statistical data, including averagesand totals as applicable, regarding response times, transport times,number of requests for assistance received, availability of resources,geographic location of requests, or any other statistical data suitableto be stored and analyzed by the system.

With reference to FIG. 3A, First Responders can log in to the system viathe “Login” modules 304. For example and as embodied herein, at 304 a, aFirst Responder can notify the system that he or she is available torespond to requests for assistance and provide information related tohis or her mode of transportation, including and without limitation,identifying that they are operating using, for example, a car, amotorcycle, a bicycle, an ambulance, and/or pedestrian transportation.Furthermore, and as embodied herein, a First Responder can specifyadditional details of resources or services that can be provided. Forexample and without limitation, a First Responder can indicate access toor availability of basic or advanced life support systems or otherresources, such as rope rescue, extrication, or any other suitableresources. For example and as embodied herein, at 304 b, the system canacknowledge the availability of the First Responder by sending a messageto the First Responder that their status is now available.

Furthermore, and as embodied herein, at 306 a the system can include anoverride function to allow the system to send out requests in certainsituations, for example when all First Responders are logged out, allFirst Responders who are logged in are currently engaged in anotherincident, or it is determined that one or more First Responderscurrently engaged in another incident should be diverted to a differentincident. For example and as embodied herein, in response to an overridecanceling one or more First Responders dispatch in an incident, at 306b, the one or more First Responders can respond to indicate availabilityfor a further incident, such as by texting “1” or “Yes” to the system.Additionally or alternatively, First Responders can log out, for exampleby sending a predetermined alphanumeric code to the system, and inresponse the system can indicate that the First Responder is no longeravailable to respond to requests for assistance. The system can send aconfirmation message to the First Responder, and can avoid sendingfurther messages to the logged out First Responder until the FirstResponder has logged in again.

Referring still to FIG. 3A, at 308, the system can request the locationof a Reporting Party requesting emergency assistance, to which theReporting Party can respond with location information, for example andwithout limitation, via a text message, voice message, smartphoneapplication, and/or GPS device. Such a Location Request can be made,periodically and/or after receiving a request for assistance, forexample to update the system with new location coordinates. Furthermore,the system can determine when a single incident (e.g., a motor vehiclecollision) has provoked more than one request from different parties,for example and without limitation, using GPS coordinates,triangulation, voice data, or text messages, and for example determiningthat a plurality of such messages specify the same or similar location.As a further alternative, a plurality of requests for assistancereceived within a predetermined time window can automatically trigger analert to the system, which can prompt review of such requests by anoperator or administrator.

With reference to FIG. 1, at 11, the system can alert one or moreregistered First Responders in the geographic catchment area. Withreference to FIG. 3B, for example and as embodied herein, at 310, thesystem can send a Request for Assistance to the one or more registeredFirst Responders in a geographic catchment area corresponding to theLocation provided by the Reporting Party. For purpose of illustrationand not limitation, as embodied herein, the Request for Assistance caninclude a text alert that the message is a “REQUEST FOR ASSISTANCE,” caninclude an Incident ID # corresponding to the Request, can include theLocation information received from the Reporting Party, and can includea prompt for the First Responder to indicate whether the First Responderis responding to the Request. For example and as embodied herein, theFirst Responder can indicate the First Responder is responding, such asby texting “1” or “Yes,” and can include a number of minutes for theFirst Responder to arrive at the reported Location. Additionally, and asembodied herein, at 312, the system can indicate to the Reporting Partythat the system is Contacting Assistance, for example by sending amessage “Contacting assistance, please wait ## minutes” (where “##” canrefer to a number of minutes that the system will await confirmationfrom one or more First Responders to the Request for Assistance).Alternatively, and as embodied herein, at 313, a First Responder candecline a Request for Assistance, such as by texting “0” or “No” to thesystem, or by not making any reply to the Request.

With reference to FIG. 1, responses from First Responders who agree todispatch to the emergency site are acknowledged at 12. With reference toFIG. 3B, for purpose of illustration and not limitation, and as embodiedherein, at 314, the system can confirm to the Reporting Party that oneor more First Responders is en route to the reported Location. Forexample and as embodied herein, the system can send a message to theReporting Party that “Help is on the way,” and can indicate to theReporting Party an expected number of minutes for one or more of theFirst Responders to arrive at the Location.

The system can utilize an adjustable algorithm to set a threshold forthe number and type of resources requested. In this manner, a suitablenumber of First Responders can be allocated to an emergency event, andthereby can avoid, for example, too many First Responders responding toa minor incident, or too few First Responders at the scene of a complexincident. For example and without limitation, and as embodied here, anincident can have a predetermined default limit on the number ofconfirmed First Responders to an incident, e.g., four, and a minimumnumber of transport vehicles, e.g., one, Alternatively, the limit orthreshold can be customized according to the expected resource demandsestimated from the underlying incident, either by the automated systemusing, for example and without limitation, a keyword or predeterminedalphanumeric code. Additionally or alternatively, the limit or thresholdcan be customized manually by a system operator. As such, and asembodied herein, at 316, if a number of First Responders indicatingavailability to respond to the Request exceeds a threshold, the systemcan indicate to the excess First Responders that “Others areresponding,” and can indicate that the excess First Responders are“Available” to respond to other Requests for Assistance. As a furtheralternative, as embodied herein, at 318, if no First Responders respondto the Request for Assistance after a predetermined amount of time, thesystem, automatically and/or upon instruction from a system operator,can indicate to the Reporting Party that “No responders are available.”

Additionally or alternatively, the system can utilize specified waitingperiods (called “chute times”) to receive confirmation from a FirstResponder. Such chute times can refer to an allowed amount of time for aresponder to prepare for and proceed en route to respond to an emergencyevent. The system can utilize an adjustable algorithm to set acceptablelimits on chute times. When the chute time limit is exceeded, FirstResponders who do not meet the threshold for requested resources and/orhave not confirmed or denied their response in reply to the originalRequest for Assistance, as described herein, can be canceled from theevent and marked as available to respond to another request forassistance, as described herein. When a response is given within thetime limit, the response can be matched against other resourceallocation criteria mentioned above. If the First Responder is accepted,the system can send a confirmation to the First Responder to proceed tothe site, as described herein. If the First Responder is rejected, thesystem can inform the First Responder that he or she is not needed andcan be marked as available to respond to further requests, as describedherein.

The system can utilize time estimates manually provided by the FirstResponder and/or calculated by the system to determine which FirstResponders are most suitable to respond to the incident and which FirstResponders are not needed to respond. For example, a First Responder tenminutes away from the scene of an incident can be selected, while aFirst Responder twenty minutes away can be denied. The system can alsoconsider and provide a suitable type or number of transportationoptions. For example. a First Responder on foot can be denied, while aFirst Responder in a vehicle can be accepted, for example if it isdetermined that vehicle transportation is required. As a furtheralternative, the system can triage all First Responders according totheir availability, the number of First Responders needed or requested,their proximity, and the resources they can provide. Cross-checkingthese variables against the threshold criteria, the system can dispatchthe closest and most appropriate resources to each scene.

Additionally or alternatively, the system can utilize an administratoror operator to input the location and initiate the response, which canbe beneficial where location descriptions, e.g., physical addresses, areinconsistent or not available. The administrator or operator can alsointervene in or alter system decisions, such as by manually allocatingor reallocating resources from one incident to another as beneficial ornecessary.

With reference to FIG. 1 at 13, the system can confirm arrival of atleast one First Responder at the requested Location. Referring now toFIG. 3C, for example and as embodied herein, at 320, the one or moreFirst Responders agreeing to dispatch to the requested Location canreceive a prompt from the system to Confirm Arrival On-Scene. Forpurpose of illustration and not limitation, as embodied herein, the oneor more First Responders can confirm arrival by sending a message of “1”or “Yes” to the system. Alternatively, the one or more First Responderscan indicate they are unable to locate the requested Location or theReporting Party, e.g., by sending a message of “2” or “Unable to locate”to the system. As a further alternative, the one or more FirstResponders can indicate that they have canceled responding to theRequest, e.g., by sending a message of “0” or “Cancel” to the system. Assuch, at 321, the system can confirm with the one or more cancelingFirst Responders that they have canceled and/or that they are nowavailable to respond to other Requests. In some cases, a request foremergency assistance may not require a response by a First Responder.For example, the incident can resolve itself, or other extenuatingcircumstances can make a response unnecessary. Furthermore, a ReportingParty can determine no assistance is needed upon arrival of a FirstResponder. The system can thus allow a First Responder to cancel theirindividual involvement, and/or the entire incident and thus other FirstResponders' involvement, additionally or alternatively, at 321.

Referring still to FIG. 3C, at 322 the system can Request a LocationUpdate from the Reporting Party. For purpose of illustration and notlimitation, as embodied herein, a location provided to the FirstResponder can be inaccurate, or can change after the initial request forassistance is made. As such, the First Responder can inform the systemthat the incident and/or Reporting Party cannot be located, therebyprompting the system to communicate with the Reporting Party to obtainan updated location and relay the updated location to the FirstResponders. For example, a Location Request can be sent to the ReportingParty in the form of a text message, such as “What is your location?”The Reporting Party can respond with an updated location, which can berelayed via text message at 324 to the First Responders. As analternative, a human operator can place a telephone call to theReporting Party to receive the location information verbally and inputthe location information into the system to be transmitted to the FirstResponders. As a further alternative, the system can utilize GPStracking or other suitable geo-location techniques, as available. Insome embodiments, the Reporting Party's location can appear, and can beupdated automatically, directly on the First Responder's mobile device.At 326, the system can send a message to the Reporting Party confirmingthat the location has been updated, and can indicate to the ReportingParty that the updated location is being communicated to the one or moreFirst Responders.

With reference to FIG. 2, at 20, the system can receive a request foradditional emergency resources, for example and without limitationadditional First Responders, transportation, or other resources, from aFirst Responder at the emergency site. For purpose of illustration andnot limitation, as embodied herein, an initial First Responder canarrive first to the requested location, and the system can inform theinitial First Responder, for example and without limitation, of a numberof other First Responders en route, the expected time of their arrival,and the type of transportation provided by these First Responders.Additionally or alternatively, referring now to FIG. 3D, the system candesignate the initial First Responder as Incident Commander, and canallow the Incident Commander to request a number, type and kind ofadditional resources suitable to resolve the emergency at 330. Forpurpose of illustration and not limitation, as embodied herein, thesystem can prompt the Incident Commander to indicate whether there is aneed for additional resources. The Incident Commander can send a messageto the system indicating “Yes” and/or a number or kind of additionalresources needed. For example, the Incident Commander can indicate anumber of vehicles requested to the Location. Alternatively, theIncident Commander can send a message to the system indicating “No” or“0” additional resources are needed.

With reference to FIG. 2, at 21, the system can notify additionalregistered responders in the geographic area of the request foradditional resources. For purpose of illustration and not limitation,with reference to FIG. 3D, at 332, if additional resources are needed,at 332, the system can send a Request for Additional Resources to theone or more registered First Responders in the geographic catchment areacorresponding to the Location of the Incident Commander. For purpose ofillustration and not limitation, as embodied herein, the Request forAdditional Resources can include an alert of “ADDITIONAL RESOURCESNEEDED” can include the Incident ID # corresponding to the Request, caninclude the Location information of the Incident Commander, and caninclude a prompt for the First Responder to indicate whether the FirstResponder is responding to the Request.

Referring again to FIG. 2, the system can obtain responses from FirstResponders at 22 agreeing to dispatch to the emergency site. For exampleand as embodied herein, the First Responder can indicate the FirstResponder is responding, such as by texting “1” or “Yes,” and caninclude a number of minutes for the First Responder to arrive at thereported Location. Alternatively, and as embodied herein, a FirstResponder can decline a Request for Additional Resources, such as bysending a message of “0” or “No” to the system. At 23, the system canobtain confirmation of the arrival of additional resources at theemergency site.

Referring still to FIG. 2, at 24, the system can obtain confirmation oftransport status. With reference to FIG. 3E, for example and withoutlimitation, as embodied herein, at 340, if the Incident Commanderindicates no additional resources are needed, as discussed above, thesystem can request confirmation from the Incident Commander, or one ormore other of the First Responders, if responding, that transportationis available or being initiated. For purpose of illustration and notlimitation, as embodied herein, the system can send a message requestingthe Incident Commander and/or one or more other First Responders to“Confirm Transport and ETA.” The Incident Commander and/or one or moreother First Responders can confirm transport by indicating a destinationfacility, the number of people being transported, and can indicate anestimated number of minutes to arrive at a destination facility.Although the destination facility is identified as a hospital in thisembodiment, any suitable destination facility can be used. Additionallyor alternatively, a plurality of destination options can be identified.The Incident Commander, one or more other First Responders and/or thesystem can indicate the target destination facility. Alternatively, theIncident Commander and/or one or more other First Responders canindicate no transportation is available or being initiated, such as bysending a message of “0” or “No.” As such, at 341, the system can send amessage to the Incident Commander and/or one or more other FirstResponders confirming “Transport [is] denied.”

Referring still to FIG. 3E, at 342, as embodied herein, the system canprovide advance notification to the destination facility to which theIncident Commander and/or one or more other First Responders hasconfirmed transport. For example and without limitation, as embodiedherein, the system can send a message to the destination facility that anumber of patients are en route to the destination facility, that anumber of vehicles are en route to the destination facility, and/or anestimated number of minutes before arrival of the transportation to thedestination facility. The message can also include any additionalinformation relayed by the First Responder, for example and withoutlimitation, a patient's vital signs or other pertinent medicalinformation

Referring now to FIG. 2, at 25, the system can confirm the arrival ofthe transportation at the destination facility. With reference to FIG.3F, for purpose of illustration and not limitation, as embodied herein,at 350, the system can prompt the Incident Commander and/or one or moreother First Responders to “Confirm arrival at hospital.” For example andwithout limitation, the system can prompt the Incident Commander and/orone or more other First Responders to confirm arrival, such as bysending a message of “1” or “Yes,” to indicate assistance is needed(e.g., if the individual being transported becomes combative or a higherlevel of care is needed), such as by sending a message of “2” or “Needassistance,” to indicate a delay in transport (e.g., a mechanicalfailure or delay due to force majeure), such as by sending a message of“3” or “Delay” and indicating a number of minutes estimated to arrive ora number of minutes of delay, and can indicate transportation has beencanceled, such as by sending a message of “0” or “Cancel.”

Referring still to FIG. 3F, at 352, the system can acknowledge anindication from the Incident Commander and/or one or more other FirstResponders that assistance is needed. For purpose of illustration andnot limitation, as embodied herein, the system can send a message to theIncident Commander and/or one or more other First Respondersacknowledging that assistance is needed, and can send a new prompt tothe Incident Commander and/or one or more other First Responders toconfirm hospital arrival, as described above, for example after suchadditional assistance is rendered.

Additionally or alternatively, at 353, the system can notify theIncident Commander and/or one or more other First Responders thatassistance is needed. For purpose of illustration and not limitation, asembodied herein, the system can send a message to the Incident Commanderand/or one or more other First Responders, either previously respondingto the Request or other First Responders in the geographical catchmentarea, indicating that the requesting Incident Commander or FirstResponder needs assistance. For example and as embodied herein, thesystem can send a message requesting that any available First Respondercall the requesting First Responder to receive instructions to renderimmediate assistance.

In addition, or as a further alternative, at 354, the system can notifythe destination facility that assistance is needed. For purpose ofillustration and not limitation, as embodied herein, the system can senda message to the destination facility requesting that the destinationfacility call the requesting First Responder to receive instructions torender immediate assistance or provide online medical direction.

Referring now to FIG. 3G, for purpose of illustration and notlimitation, as embodied herein, at 356, the system can send anindication to the destination facility, for example, when the IncidentCommander and/or one or more other First Responders indicates a delay intransport, as described herein. For example and without limitation, asembodied herein, the system can send a message to the destinationfacility indicating a number of patients transported by the IncidentCommander and/or one or more other First Responders will be delayed by anumber of minutes, as indicated above by the Incident Commander and/orone or more other First Responders. Additionally or alternatively, inresponse to a notification regarding delay of resources, the system,receiving facility or other First Responders can contact the delayedresources to obtain updated information regarding the delay and/or cancontact additional First Responders or resources to replace the delayedresources.

Alternatively, for purpose of illustration and not limitation, asembodied herein, at 358, the system can notify the destination facilitythat transportation has been canceled. For purpose of illustration andnot limitation, as embodied herein, the Incident Commander and/or one ormore other First Responders can inform the system that the emergencysituation has ended or otherwise been resolved, as described herein.This can occur, for example, when a request for emergency assistancedoes not warrant transportation, such as when the Reporting Party optsto self-transport, or other circumstances make transport unnecessary orundesirable. The system can allow a First Responder to canceltransportation, thus ending the involvement of transportation in theincident and marking the transportation resource as “Available.” Forexample, and as embodied herein, the system can send a cancellation viaa text message or numerical code to the destination facility indicatingthat transportation of people by the Incident Commander and/or one ormore other First Responders is canceled.

Additionally or alternatively, for purpose of illustration and notlimitation, as embodied herein, at 359, the system can confirm with theIncident Commander and/or one or more other First Responders thattransportation has been canceled. For example and without limitation, asembodied herein, the system can notify the Incident Commander and/or oneor more other First Responders that they are available to respond toanother Request for Assistance.

In addition or as a further alternative, as embodied herein, for purposeof illustration and not limitation, as embodied herein, at 360, thesystem can confirm with the Incident Commander and/or one or more otherFirst Responders that the response is complete. For example and withoutlimitation, and as embodied herein, when the Incident Commander and/orone or more other First Responders has confirmed arrival at thedestination facility or has otherwise indicated that the request isresolved or completed, the system can notify the Incident Commanderand/or one or more other First Responders that they are available torespond to another Request for Assistance.

In some embodiments, a summary report of response times can be providedto the First Responder. The summary report can summarize response timesfor certain actions during one or more previous requests for emergencyassistance, for example arrival at the emergency site, arrival at anemergency facility, or any other actions performed. For example, and asembodied herein, a summary report can be provided to any First Responderthat has agreed to respond to an emergency event, for example as at 12.Furthermore, and as embodied herein, a summary report can be provided ifany actions are performed during response to a request, regardless ifthe response to the emergency event is completed by the First Responder.Alternatively, a summary report can be provided if certain actions areperformed during response to a request, for example if the response tothe emergency event is completed by the First Responder. For example,and as embodied herein, a First Responder can agree to respond to arequest and provide transportation to an emergency facility. Uponconfirmation of the First Responders availability following respondingto the request and providing transportation, the system can provideresponse times for any actions performed by the First Responder.Alternatively, the First Responder can agree to respond to a request,and can later cancel the response, for example upon arrival to the sceneof the emergency event. As such, the system can provide a summary reportto the First Responder including only the actions performed, forexample, the time of confirmation to respond to the event, the time ofarrival to the scene of the emergency event, and the time at which theFirst Responder became available for response to a subsequent emergencyevent.

Furthermore, the system can coordinate all First Responders, as well asthose who need to be transported to a receiving facility, for exampleand without limitation a hospital, as embodied herein by utilizing amultistep function to track several variables. For example and withoutlimitation, and as embodied herein, the system can track the receivingfacility, the number of individuals being transported, and the estimatedtime of arrival. Such variables can be conveyed to the system, forexample and without limitation, using alphanumeric codes and/ornumerical values, as described herein. As embodied herein, analphanumeric code representing a receiving facility, along with thenumber of individuals being transported and the length of time estimatedto arrival can each be entered as numerical values. For example andwithout limitation, to inform the system that First Responders are enroute to a receiving facility represented as “1” to deliver one patientin an estimated time of fifteen minutes, the data can be input to thesystem in a single message separated by markers, for example as“1*1*15”.

In some embodiments, a software system can form the core of emergencydispatching and response utility. The software program can operate on apersonal computer with a USB modem or GSM modem and enabled with a SIMcard, utilizing a unique number—e.g., “911”—which can serve as auniversal public access number in a predetermined geographic area—i.e.,the catchment area. A backup of the software program can also bemaintained on a server. Another embodiment of the disclosed methods canbe a software program that can be used on both feature phones andsmartphones, with all the associated applications and features (e.g.,GPS, touchscreen, icons).

Additionally or alternatively, as embodied herein, the emergencydispatch systems described herein can be integrated within existingdispatch systems to increase capacity and/or expand the area of coverageof such existing systems. For example, a universal emergency number canbe utilized in a region to access an existing emergency dispatch systemin a certain coverage area, for example in an urban center, and thesystem according to the disclosed subject matter can be configured torelay requests for assistance using the universal emergency numberoriginating outside the coverage area to registered responders asdescribed herein. Furthermore, and as embodied herein, the system can beconfigured to relay requests for assistance using the universalemergency number to registered responders as described herein when thecapacity for the existing emergency dispatch system is exceeded.

The disclosed methods and systems can enable the alerting, dispatchingand response necessary to provide emergency dispatching to multiplefirst responders simultaneously. In some embodiments, the system can beutilized by hospitals, EMS agencies, fire departments and other publicand private emergency responder organizations and schemes. The systemcan track emergency incidents, including the location of andcommunications between reporting parties and eyewitnesses, responders,transportation, and receiving facilities. The system can relaycommunications and incident information between all parties, coordinatetheir response, and triage essential resources during large-scale and/ormultiple concurrent incidents. In some embodiments, the system can usevoice, text and/or digital information. Furthermore, and as embodiedherein, the system can store any data and information related torequests for assistance and associated response, including responsetimes, geographic locations, or any other suitable data, and can supportreal-time updates and a web-based interface. In some embodiments, thesystem can interface with other emergency 911 systems. Additionally oralternatively, the system can operate as an “over-the-top” system, forexample operating as an alternative to text messaging or internetservices provided by a mobile network operator.

Advantages of the disclosed subject matter include, without limitation,reduced delays in accessing emergency medical care and transport,reduced financial costs compared with conventional dispatchingtechnologies and associated infrastructure, accessibility to populationswith low literacy rates and limited education, utilization ofreadily-available resources such as mobile phones, USB modems, andlaptops; ease of deployability with minimal centralized informationtechnology requirements, adaptability to a variety of settings anddeployment scenarios, including but not limited, cruise lines, train andtrucking routes, mining, oil fields, concerts, parades, campuses, parksand multi-story buildings.

Whereas conventional systems can rely on a limited number of designatedambulances to provide response throughout a given geographic area, thesystems and techniques of the disclosed subject matter can invertdispatching algorithms to effectively increase the number of availableemergency transport vehicles within a community at any given time. As aresult, for example and without limitation, instead of sendingindividual ambulances to seek out a patient and return with them to thehospital—much like a boomerang—the disclosed system can provide anextended range by alerting all First Responders in an area whereemergency response is needed, and then coordinating the nearestavailable responders who can provide appropriate and safe transport. Thesystems and techniques of the disclosed subject matter can utilizeexisting mobile communication infrastructure, including and withoutlimitation mobile messaging services, SMS gateways and/or mobileapplications, to send out a telecommunication signal that all FirstResponders can see whenever an emergency occurs. As described herein,the systems and techniques can coordinate an emergency response by thoseFirst Responders who are able and most suitable to respond.

To account for low levels of literacy, the systems and techniquesaccording to the disclosed subject matter can be both legible andflexible. Alphanumeric messages and/or mobile applications, for bothtext message capable phones and smartphones, as appropriate, can bewritten with a lowest-common-denominator approach, such that basicconcepts can be communicated simply and effectively in any language,using any typeset or visual icons, to coordinate emergency responsefunctions including, without limitation, Alert, Response, Arrival,Additional Resources, Transport, and Patient Turnover. Furthermore, thesystems and techniques according to the disclosed subject matter cansimultaneously initiate, process, and track any number of individual andgrouped messages, including messages from individuals prone to humanerror. For example and as described herein, the systems and techniquescan guide an emergency response from request to completion, while alsoaccounting for a variety of factors inherent to emergency response.

FIG. 4 illustrates a mobile client device for use with the system. Themobile client device, for example and without limitation, can include atext message enabled mobile phones and/or a smartphone 200. The user caninteract with the system via alphanumeric text messages, for example andwithout limitation using SMS messaging, or using a mobile softwareapplication configured to interact with the system. The system canutilize integrated geo-location sensors, if available, including GPS andWiFi-based geo-location services to receive location information of theuser. The mobile client device can be used by the Reporting Party, forexample and without limitation to request emergency response services,and can be used by First Responders to coordinate an emergency responseas discussed herein.

For purpose of illustration and not limitation, and as embodied herein,interactions can be performed by touching the touch screen 405. However,other interactions can be performed using other forms of input. Forexample, a user interaction can be performed by pressing a stylus to aregion of the screen, or by moving a pointer to a particular region of ascreen, such as by using a mouse or other pointing device. Further,interactions can be performed directly, or can be performed remotely,for example by using a remote control. Such interactions can also beperformed by a motion not directly making contact with device 200, orwith any other device. In this manner, a motion can be captured bysensor 410, which can be an optical sensor or motion sensor, for examplea video camera, and the motion can be determined by device 200 to be auser interaction.

FIG. 5 illustrates an example computer system 700. In particularembodiments, one or more computer systems 700 perform one or more stepsof one or more methods described or illustrated herein. In particularembodiments, one or more computer systems 700 provide functionalitydescribed or illustrated herein. In particular embodiments, softwarerunning on one or more computer systems 700 performs one or more stepsof one or more methods described or illustrated herein or providesfunctionality described or illustrated herein. Particular embodimentsinclude one or more portions of one or more computer systems 700.

This disclosure contemplates any suitable number of computer systems700. This disclosure contemplates computer system 700 taking anysuitable physical form. As example and not by way of limitation,computer system 700 may be an embedded computer system, a system-on-chip(SOC), a single-board computer system (SBC) (such as, for example, acomputer-on-module (COM) or system-on-module (SOM)), a desktop computersystem, a laptop or notebook computer system, an interactive kiosk, amainframe, a mesh of computer systems, a mobile telephone, a personaldigital assistant (PDA), a server, a tablet computer system, or acombination of two or more of these. Where appropriate, computer system700 may include one or more computer systems 700; be unitary ordistributed; span multiple locations; span multiple machines; spanmultiple datacenters; or reside in a cloud, which may include one ormore cloud components in one or more networks. Where appropriate, one ormore computer systems 700 may perform without substantial spatial ortemporal limitation one or more steps of one or more methods describedor illustrated herein. As an example and not by way of limitation, oneor more computer systems 700 may perform in real time or in batch modeone or more steps of one or more methods described or illustratedherein. One or more computer systems 700 may perform at different timesor at different locations one or more steps of one or more methodsdescribed or illustrated herein, where appropriate.

In particular embodiments, computer system 700 includes a processor 702,memory 704, storage 706, an input/output (I/O) interface 708, acommunication interface 710, and a bus 712. Although this disclosuredescribes and illustrates a particular computer system having aparticular number of particular components in a particular arrangement,this disclosure contemplates any suitable computer system having anysuitable number of any suitable components in any suitable arrangement.

In particular embodiments, processor 702 includes hardware for executinginstructions, such as those making up a computer program. As an exampleand not by way of limitation, to execute instructions, processor 702 mayretrieve (or fetch) the instructions from an internal register, aninternal cache, memory 704, or storage 706; decode and execute them; andthen write one or more results to an internal register, an internalcache, memory 704, or storage 706. In particular embodiments, processor702 may include one or more internal caches for data, instructions, oraddresses. Although this disclosure describes and illustrates aparticular processor, this disclosure contemplates any suitableprocessor.

In particular embodiments, memory 704 includes main memory for storinginstructions for processor 702 to execute or data for processor 702 tooperate on. As an example and not by way of limitation, computer system700 may load instructions from storage 706 or another source (such as,for example, another computer system 700) to memory 704. Processor 702may then load the instructions from memory 704 to an internal registeror internal cache. To execute the instructions, processor 702 mayretrieve the instructions from the internal register or internal cacheand decode them. During or after execution of the instructions,processor 702 may write one or more results (which may be intermediateor final results) to the internal register or internal cache. Processor702 may then write one or more of those results to memory 704. Inparticular embodiments, processor 702 executes only instructions in oneor more internal registers or internal caches or in memory 704 (asopposed to storage 706 or elsewhere) and operates only on data in one ormore internal registers or internal caches or in memory 704 (as opposedto storage 706 or elsewhere). One or more memory buses (which may eachinclude an address bus and a data bus) may couple processor 02 to memory704. Bus 712 may include one or more memory buses, as described below.In particular embodiments, one or more memory management units (MMUs)reside between processor 702 and memory 704 and facilitate accesses tomemory 704 requested by processor 702. Although this disclosuredescribes and illustrates particular memory, this disclosurecontemplates any suitable memory.

In particular embodiments, storage 706 includes mass storage for data orinstructions. Storage 706 may include removable or non-removable (i.e.,fixed) media, where appropriate. Storage 706 may be internal or externalto computer system 700, where appropriate. In particular embodiments,storage 706 is non-volatile, solid-state memory. Where appropriate,storage 706 may include one or more storages 706. Although thisdisclosure describes and illustrates particular storage, this disclosurecontemplates any suitable storage.

In particular embodiments, I/O interface 708 includes hardware,software, or both providing one or more interfaces for communicationbetween computer system 700 and one or more I/O devices. Computer system700 may include one or more of these I/O devices, where appropriate. Oneor more of these I/O devices may enable communication between a personand computer system 700. As an example and not by way of limitation, anI/O device may include a keyboard, keypad, microphone, monitor, mouse,printer, scanner, speaker, still camera, stylus, tablet, touch screen,trackball, video camera, another suitable I/O device or a combination oftwo or more of these. An I/O device may include one or more sensors.This disclosure contemplates any suitable I/O devices and any suitableI/O interfaces 708 for them. Where appropriate, I/O interface 708 mayinclude one or more device or software drivers enabling processor 702 todrive one or more of these I/O devices. I/O interface 708 may includeone or more I/O interfaces 708, where appropriate. Although thisdisclosure describes and illustrates a particular I/O interface, thisdisclosure contemplates any suitable I/O interface.

In particular embodiments, communication interface 710 includeshardware, software, or both providing one or more interfaces forcommunication (such as, for example, packet-based communication) betweencomputer system 700 and one or more other computer systems 700 or one ormore networks. As an example and not by way of limitation, communicationinterface 710 may include a network interface controller (NIC) ornetwork adapter for communicating with an Ethernet or other wire-basednetwork or a wireless NIC (WNIC) or wireless adapter for communicatingwith a wireless network, such as a Wi-Fi network. This disclosurecontemplates any suitable network and any suitable communicationinterface 710 for it. Although this disclosure describes and illustratesa particular communication interface, this disclosure contemplates anysuitable communication interface.

In particular embodiments, bus 712 includes hardware, software, or bothcoupling components of computer system 700 to each other. Although thisdisclosure describes and illustrates a particular bus, this disclosurecontemplates any suitable bus or interconnect.

Herein, reference to a computer-readable storage medium encompasses oneor more non-transitory, tangible, computer-readable storage mediapossessing structure. As an example and not by way of limitation, acomputer-readable storage medium may include a semiconductor-based orother integrated circuit (IC) (such, as for example, afield-programmable gate array (FPGA) or an application-specific IC(ASIC)), a hard disk, an HDD, a hybrid hard drive (HHD), an opticaldisc, an optical disc drive (ODD), a magneto-optical disc, amagneto-optical drive, a floppy disk, a floppy disk drive (FDD),magnetic tape, a holographic storage medium, a solid-state drive (SSD),a RAM-drive, a SECURE DIGITAL card, a SECURE DIGITAL drive, or anothersuitable computer-readable storage medium or a combination of two ormore of these, where appropriate. Herein, reference to acomputer-readable storage medium excludes any medium that is noteligible for patent protection under 35 U.S.C. §101. Herein, referenceto a computer-readable storage medium excludes transitory forms ofsignal transmission (such as a propagating electrical or electromagneticsignal per se) to the extent that they are not eligible for patentprotection under 35 U.S.C. §101. A computer-readable non-transitorystorage medium may be volatile, non-volatile, or a combination ofvolatile and non-volatile, where appropriate.

This disclosure contemplates one or more computer-readable storage mediaimplementing any suitable storage. In particular embodiments, acomputer-readable storage medium implements one or more portions ofprocessor 702 (such as, for example, one or more internal registers orcaches), one or more portions of memory 704, one or more portions ofstorage 706, or a combination of these, where appropriate. In particularembodiments, a computer-readable storage medium implements RAM or ROM.In particular embodiments, a computer-readable storage medium implementsvolatile or persistent memory. In particular embodiments, one or morecomputer-readable storage media embody software. Herein, reference tosoftware may encompass one or more applications, bytecode, one or morecomputer programs, one or more executables, one or more instructions,logic, machine code, one or more scripts, or source code, and viceversa, where appropriate. In particular embodiments, software includesone or more application programming interfaces (APIs). This disclosurecontemplates any suitable software written or otherwise expressed in anysuitable programming language or combination of programming languages.In particular embodiments, software is expressed as source code orobject code.

In addition to the specific embodiments disclosed above and/or claimedbelow, the disclosed subject matter is also directed to otherembodiments having any other possible combination of the dependentfeatures claimed below and those disclosed above. As such, theparticular features disclosed herein can be combined with each other inother manners within the scope of the disclosed subject matter such thatthe disclosed subject matter should be recognized as also specificallydirected to other embodiments having any other possible combinations.Thus, the foregoing description of specific embodiments of the disclosedsubject matter has been presented for purposes of illustration anddescription. It is not intended to be exhaustive or to limit thedisclosed subject matter to those embodiments disclosed.

It will be apparent to those skilled in the art that variousmodifications and variations can be made in the method and system of thedisclosed subject matter without departing from the spirit or scope ofthe disclosed subject matter. Thus, it is intended that the disclosedsubject matter include modifications and variations that are within thescope of the appended claims and their equivalents.

1. A computerized method for coordinating decentralized response toemergency events, comprising: receiving at least one request foremergency assistance; alerting registered responders in a geographicarea corresponding to an emergency site of said request for emergencyassistance; acknowledging a response from at least one of the respondersagreeing to dispatch to the emergency site; and confirming arrival ofsaid at least one responder at the emergency site.
 2. The method ofclaim 1, further comprising: receiving a request for additionalresources from the at least one responder; notifying at least oneadditional responder in the geographic area of the request foradditional resources; obtaining a response from the at least oneadditional responder agreeing to dispatch to the emergency site;attaining confirmation of the arrival of the at least one additionalresponder at the emergency site; confirming a transportation status anda destination facility from the emergency site; confirming arrival ofthe emergency transportation at the destination facility; and confirmingavailability of the at least one responder.
 3. The method of claim 2,further comprising providing a summary report of response times to theat least one responder.
 4. The method of claim 1, further comprising:determining a threshold number of resources to respond to the at leastone request; and allocating a number of the responders not to exceed thethreshold number of resources.
 5. The method of claim 1, whereinconfirming arrival of said at least one responder comprises receivingupdated location information of the emergency site from said at leastone responder at the emergency site.
 6. The method of claim 1, furthercomprising storing location information of the emergency site, andproducing reports and statistics based on the location information. 7.The method of claim 1, further comprising recording and storingcommunications between reporting parties, responders, and receivingfacilities for tracking.
 8. The method of claim 1, further comprisingdetermining a response time of the at least one responder and storingthe at least one response time.
 9. The method of claim 1, furthercomprising determining a suitable level of support for the request foremergency assistance.
 10. The method of claim 9, further comprisingcanceling previously sent requests to responders when the suitable levelof support has been confirmed.
 11. A computer system for coordinatingdecentralized response to emergency events, comprising: one or morememories; and one or more processors coupled to the one or morememories, wherein the processors are configured to: receive at least onerequest for emergency assistance; alert registered responders in ageographic area corresponding to an emergency site of said request foremergency assistance; acknowledge a response from at least one of theresponders agreeing to dispatch to the emergency site; confirm arrivalof the at least one of the responders at the emergency site;
 12. Thesystem of claim 11, wherein the one or more processors are furtherconfigured to: receive a request for additional resources from the atleast one responder; notify at least one additional responder in thegeographic area of the request for additional resources; obtain aresponse from the at least one additional responder agreeing to dispatchto the emergency site; attain confirmation of the arrival of the atleast one additional responder at the emergency site; attainconfirmation of a transportation status and a destination facility;confirm arrival of the emergency transportation at the destinationfacility; confirm availability of the at least one responder.
 13. Thesystem of claim 12, wherein the one or more processors are furtherconfigured to provide a summary report of response times to the at leastone responder.
 14. The system of claim 11, wherein the one or moreprocessors are further configured to receive updated locationinformation of the emergency site from said at least one responder atthe emergency site.
 15. The system of claim 11, wherein the one or moreprocessors are further configured to store location information of theemergency site for tracking.
 16. The system of claim 11, wherein the oneor more processors are further configured to record and storecommunications between reporting parties, responders, and receivingfacilities for tracking.
 17. The system of claim 11, wherein the one ormore processors are further configured to determine a response time ofthe at least one responder and store the at least one response time. 18.The system of claim 11, wherein the one or more processors are furtherconfigured to determine a suitable level of support for the request foremergency assistance.
 19. The system of claim 18, wherein the one ormore processors are further configured to cancel previously sentrequests to responders when the suitable level of support has beenconfirmed.
 20. The system of claim 18, wherein the one or moreprocessors are further configured to receive requests input by anoperator.